The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Mail transfer agents (MTA's) typically receive a large number of email messages from many different senders for delivery to many recipients. The number of email messages can range from hundreds of messages per hour to hundreds of thousands of messages per hour. Because of the increasing problems of the tremendous volume of unsolicited commercial email (i.e., spam) and from a significant percentage of email messages being infected with viruses, administrators of MTA's would like to be able to control the number of connections to the MTA's and to manage the delivery of the many email messages to in an easy to administer and efficient manner as part of the efforts to deal with spam and virus infected email messages.
However, traditional approaches for managing the flow of email messages through an MTA allow for handling senders and recipients of the email messages separately. For example, if the administrator of the MTA has observed that a particular Internet Protocol (IP) address has been sending a large amount of spam, the administrator can configure the MTA to refuse to accept email messages from the particular IP address. Over time, the administrator will likely identify a large number of IP addresses that send spam to the MTA, and for each such IP address, the administrator must separately configure the MTA to refuse email messages. The same situation can arise for email messages from particular IP addresses that are identified as being infected with a virus.
Due to the growing proliferation of spam and viruses, the administrator is faced with the dilemma of either constantly monitoring the flow of email messages for spam and virus infected email messages and continually reconfiguring the MTA to reject email messages from the offending IP addresses, or the administrator can limit the time spent in such efforts to dealing with just the biggest sources of such offending email messages while letting other smaller sources go unchecked.
Similarly, there are a large number of recipients for the large number of email messages handled by the MTA. Traditional approaches allow the administrator to configure the MTA to always allow or always block a particular recipient, but the MTA must be configured separately for each recipient. Furthermore, there are situations in which a sender of a large number of email messages is incorrectly identified as a spammer, and as a result, the administrator configures the MTA to reject email messages from the spammer's IP address. However, when the sender attempts to contact the administrator of the MTA to determine why the sender's email messages are being rejected, that inquiry typically comes from the same blocked IP address, and as a result, the sender who is incorrectly identified as a spammer must use other means to contact the administrator, which can be significantly more inconvenient for the sender and can result in a worsening of the relationship between the sender and the administrator of the MTA.
Based on the foregoing, it is desirable to provide improved techniques for managing the flow of email messages to an MTA that can enable the administrator of the MTA to more efficiently and effectively deal with different senders of undesired email messages. Furthermore, there is a need for an approach for more effectively processing email messages at an MTA that can enable the administrator to more efficiently configure the MTA to handle email messages addressed to different recipients served by the MTA.